1. Technical Field
The present invention relates in general to a system and method for managing off-screen buffers in a computer system. More particularly, the present invention relates to a system and method for managing Java Swing's off-screen buffer used for displaying graphics on a display device.
2. Description of the Related Art
Swing is a graphical user interface (GUI) toolkit that has been developed for the Java programming language. Essentially, Swing is a component framework built over parts of the older Abstract Windowing Toolkit (AWT) for visually displaying the Java output.
Swing components include a variety of graphical components such as labels, buttons, panels, sliders, lists, trees, and other graphical components. Because Swing is written in the Java programming language it is able to run on any computer platform (i.e., MS-Windows, UNIX, Apple MacIntosh, etc.) that includes a compatible Java virtual machine.
Swing is part of the Java Foundation Class (JFC). The JFC are a collection of packages that developers can use to create full featured applications in Java. The JFC includes Swing, AWT, Accessibility, Java 2D, and Drag and Drop functionality. Swing provides applications with increased portability across computer platforms as well as graphical “look and feel” that can be set within an application during runtime. These features allow an application running on an IBM AIX™ platform to use the same Swing code and have the same look and feel as an application running on a Microsoft Windows platform.
While Swing offers developers certain advantages over other graphical development tools, it currently also faces various challenges. One challenge is that Swing code may be slightly slower than native languages, such as the Microsoft Foundation Class (MFC), because Swing is written in Java. Another challenge is that the screen image is built in an off-screen buffer that is managed by Java's Repaint Manager. The off-screen buffer may be destroyed and recreated numerous times during an application's use. The repeated destruction and re-creation of the off-screen buffer negatively impacts system performance. This performance impact is especially noticeable in Java applications where multiple “heavyweight” Java components are being used. Heavyweight components include all of the ready-to-use AWT components (such as Frame, Dialog, and ScrollPane) and all components that inherit from the AWT Canvas and Panel classes.
The off-screen buffer is similar to a bitmap where the various graphical components are written. When all the graphical components are written to the off-screen buffer, it is painted onto the display device by the Repaint Manager. When a heavyweight component is invoked (e.g., by the user selecting a heavyweight component, such as a Dialog), the existing off-screen buffer is destroyed and is recreated by the Repaint Manager. Conversely, when lightweight (i.e., Swing based components) are used, the off-screen buffer is not destroyed and the lightweight component is written to the existing off-screen buffer along with the heavyweight component and any other light weight components.
Sharing of the off-screen buffer continues until either more space is needed in the off-screen buffer (i.e., the components take up more screen space), or when a different heavyweight component is selected. When either of these conditions occur, the current off-screen buffer is destroyed and a new one is created by the Repaint Manager. As mentioned before, this repeated destruction and creation of the off-screen buffer is particularly challenging in applications where two or more heavyweight components are repeatedly invoked, thereby causing the buffer to repeatedly be destroyed and re-created causing system performance to degrade.
What is needed, therefore, is a system and method in which the Java Swing's off-screen buffer is shared among multiple heavyweight components.